home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-manning-dns-nsap-02.txt < prev    next >
Text File  |  1993-06-07  |  20KB  |  647 lines
  1.  
  2. Network Working Group                       B. Manning (Rice University)
  3. INTERNET DRAFT                                         R. Colella (NIST)
  4.                                                              May 7, 1993
  5.  
  6.  
  7.                         DNS NSAP Resource Records
  8.  
  9.  
  10.  
  11. Status of This Memo
  12.  
  13.  
  14. This document is an Internet-Draft. Internet-Drafts are working
  15. documents of the Internet Engineering Task Force (IETF), its Areas, and
  16. its Working Groups. Note that other groups may also distribute working
  17. documents as Internet-Drafts.
  18.  
  19.  
  20. Internet-Drafts are draft documents valid for a maximum of six months.
  21. Internet-Drafts may be updated, replaced, or obsoleted by other
  22. documents at any time. It is not appropriate to use Internet-Drafts as
  23. reference material or to cite them other than as a "working draft" or
  24. "work in progress."
  25.  
  26.  
  27. To learn the status of any Internet-Draft, please check the 1id-
  28. abstract.txt listing contained in the Internet-Drafts Shadow Directories
  29. on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
  30. munnari.oz.au.
  31.  
  32.  
  33. It is intended that this document will be submitted to the IESG for
  34. consideration as a standards document. Distribution of this document is
  35. unlimited.
  36.  
  37.  
  38.                                     Abstract
  39.  
  40.  
  41.  
  42. The Internet is moving towards the deployment of an OSI lower layers
  43. infrastructure. This infrastructure comprises the connectionless network
  44. protocol (CLNP) and supporting routing protocols. Also required as part
  45. of this infrastructure is support in the Domain Name System (DNS) for
  46. mapping between names and NSAP addresses.
  47.  
  48.  
  49. This document defines the format of two new Resource Records (RRs) for
  50. the DNS, building upon earlier work in RFC 1348. This format may be used
  51. with any NSAP address format.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Expiration Date November 7, 1993                                [Page 1]
  59.  
  60. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  61.  
  62.  
  63. 1   Introduction
  64.  
  65.  
  66. The Internet is moving towards the deployment of an OSI lower layers
  67. infrastructure. This infrastructure comprises the connectionless network
  68. protocol (CLNP) [ISO86b] and supporting routing protocols. Also required
  69. as part of this infrastructure is support in the Domain Name System
  70. (DNS) [Moc87a , Moc87b] for mapping between DNS names and OSI Network
  71. Service Access Point (NSAP) addresses [ISO88] [Note: NSAP and NSAP
  72. address are used interchangeably throughout this memo].
  73.  
  74.  
  75. This document defines the format of two new Resource Records (RRs) for
  76. the DNS, building upon earlier work in RFC 1348. This format may be used
  77. with any NSAP address format.
  78.  
  79.  
  80. This memo assumes that the reader is familiar with the DNS. Some
  81. familiarity with NSAPs is useful; see [CGC91] or [ISO88] for additional
  82. information.
  83.  
  84.  
  85. 2   Background
  86.  
  87.  
  88. The reason for defining DNS mappings for NSAPs is to support CLNP
  89. in the Internet. Debugging with CLNP ping and traceroute is becoming
  90. more difficult with only numeric NSAPs as the scale of deployment
  91. increases. Current debugging is supported by maintaining and exchanging
  92. a configuration file with name/NSAP mappings similar in function to
  93. hosts.txt. This suffers from the lack of a central coordinator for this
  94. file and also from the perspective of scaling. The former is the most
  95. serious short-term problem. Scaling of a hosts.txt-like solution has
  96. well-known long-term scaling difficiencies.
  97.  
  98.  
  99. A second reason for this work is the proposal to use CLNP as a re-
  100. placement for IP: "TCP and UDP with Bigger Addresses (TUBA), A Simple
  101. Proposal for Internet Addressing and Routing" [Cal92]. Should this pro-
  102. posal be selected, the DNS must be capable of supporting CLNP addresses.
  103.  
  104.  
  105. 3   Scope
  106.  
  107.  
  108. The RRs defined in this paper support all known NSAP formats. This
  109. includes support for the notion of a custom-defined NSAP format based on
  110. an AFI obtained by the IAB for use in the Internet.
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. B. Manning/R. Colella                                           [Page 2]
  118.  
  119. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  120.  
  121.  
  122. As a point of reference, there is a distinction between registration
  123. and publication of addresses. For IP addresses, the IANA is the root
  124. registration authority and the DNS a publication method. For NSAPs,
  125. addendum two of the network service definition, ISO8348/Ad2 [ISO88],
  126. is the root registration authority and this memo defines how the DNS
  127. is used as a publication method.
  128.  
  129.  
  130. 4   Structure of NSAPs
  131.  
  132.  
  133. NSAPs are hierarchically structured to allow distributed administration
  134. and efficient routing. Distributed administration permits subdelegated
  135. addressing authorities to, as allowed by the delegator, further
  136. structure the portion of the NSAP space under their delegated control.
  137. Accommodation of this distributed authority requires flexibility in the
  138. DNS inverse mapping of NSAPs to names, allowing sub-authorities to
  139. represent the substructure they define, if any, in the DNS as well as
  140. the NSAP values themselves.
  141.  
  142.  
  143. While all NSAP structures currently known to be in use in the Internet
  144. have fixed field sizes (e.g., [CGC91, Bry92]), some NSAP formats defined
  145. in ISO8348/Ad2 define one of the fields as variable-sized. These formats
  146. are still parsable, since the total NSAP length is known and there is,
  147. at most, one variable-sized field. These formats are accommodated in this
  148. document, even though there is no current requirement.
  149.  
  150.  
  151. For the purposes of this memo, NSAPs can be thought of as a tree of
  152. identifiers. The root of the tree is defined in ISO8348/Ad2 [ISO88],
  153. and has as its immediately registered subordinates the one-octet
  154. Authority and Format Identifiers (AFIs) defined there. The size of
  155. subsequently-defined fields depends on which branch of the tree is
  156. taken. The depth of the tree varies according to the authority
  157. responsible for defining subsequent fields.
  158.  
  159.  
  160. An example is the authority under which US GOSIP defines NSAPs [GOSIP].
  161. Under the AFI of 47, NIST (National Institute of Standards and Technol-
  162. ogy) obtained a value of 0005 (the AFI of 47 defines the next field as
  163. being two octets consisting of four BCD digits from the International
  164. Code Designator space [ISO84]). NIST defined the subsequent fields in
  165. [GOSIP], as shown in Figure 1. The field immediately following 0005 is
  166. a format identifier for the rest of the US GOSIP NSAP structure, with
  167. a hex value of 80. Following this is the three-octet field, values for
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175. B. Manning/R. Colella                                           [Page 3]
  176.  
  177. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  178.  
  179. which are allocated to network operators; the registration authority for
  180. this field is delegated to GSA (General Services Administration).
  181.  
  182.              _______________
  183.             |_<--_IDP_-->__|______________________________________
  184.             |_AFI_|__IDI___|____________<--_DSP_-->______________|
  185.             |_47__|_0005__|_DFI_|_AA_|Rsvd_|_RD_|Area_|_ID_|Sel__|
  186.      octets |__1__|___2____|_1__|_3__|__2___|2__|__2___|6__|__1__|
  187.  
  188.  
  189.                     IDP    Initial Domain Part
  190.                     AFI    Authority and Format Identifier
  191.                     IDI    Initial Domain Identifier
  192.                     DSP    Domain Specific Part
  193.                     DFI    DSP Format Identifier
  194.                     AA     Administrative Authority
  195.                     Rsvd   Reserved
  196.                     RD     Routing Domain Identifier
  197.                     Area   Area Identifier
  198.                     ID     System Identifier
  199.                     SEL    NSAP Selector
  200.  
  201.  
  202.                   Figure 1: GOSIP Version 2 NSAP structure.
  203.  
  204.  
  205. The last octet of the NSAP is the NSelector (NSel). In practice, the
  206. NSAP minus the NSel identifies the CLNP protocol machine on a given
  207. system, and the NSel identifies the CLNP user. Since there can be more
  208. than one CLNP user (meaning multiple NSel values for a given "base"
  209. NSAP), the representation of the NSAP should be CLNP-user independent.
  210. To achieve this, an NSel value of zero will be used with all NSAP values
  211. stored in the DNS. An NSAP with NSel=0 identifies the network layer
  212. itself. It is left to the application retrieving the NSAP to determine
  213. the appropriate value to use in that instance of communication.
  214.  
  215.  
  216. In the event that CLNP is used to support TCP and UDP services, the
  217. NSel value used will be the appropriate IP PROTO value as registered
  218. with the IANA. For "standard" OSI, the selection of NSel values is left
  219. as a matter of local administration. Administrators of systems that
  220. support the OSI transport protocol [ISO86a] in addition to TCP/UDP
  221. will select NSels for use by OSI Transport that do not conflict with
  222. the IP PROTO
  223. values.
  224.  
  225.  
  226. In Master Files and in the printed text in this memo, NSAPs are
  227. represented as a string of "."-separated hex values. The values
  228. correspond to convenient divisions of the NSAP to make it more readable.
  229. For example, the "."-separated fields might correspond to the NSAP
  230. fields as defined by the appropriate authority (ISoc, GOSIP, ANSI,
  231. etc.). The use of this notation is strictly for readability. The "."s do
  232.  
  233.  
  234.  
  235. B. Manning/R. Colella                                           [Page 4]
  236.  
  237. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  238.  
  239. not appear in DNS packets. For example, a printable representation of
  240. the first four fields of a US GOSIP NSAP might look like
  241.  
  242.  
  243.                             47.0005.80.005a00
  244.  
  245.  
  246. and a full US GOSIP NSAP might appear as
  247.  
  248.  
  249.           47.0005.80.005a00.0000.1000.0020.00800a123456.00.
  250.  
  251.  
  252. For more information on US GOSIP NSAPs, see RFC1237 [CGC91]. Other NSAP
  253. formats have different fields and field widths (see [Bry92]).
  254.  
  255.  
  256. 5   The NSAP RR
  257.  
  258.  
  259. The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 (decimal).
  260. Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously
  261. to IP address lookup. A query is generated by the resolver requesting an
  262. NSAP RR for a provided DNS name.
  263.  
  264.  
  265. NSAP RRs conform to the top level RR format and semantics as defined in
  266. Section 3.2.1 of RFC 1035.
  267.  
  268.  
  269.                                      1  1  1  1  1  1
  270.        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  271.      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  272.      |                                               |
  273.      /                                               /
  274.      /                    NAME                       /
  275.      |                                               |
  276.      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  277.      |                 TYPE = NSAP                   |
  278.      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  279.      |                 CLASS = IN                    |
  280.      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  281.      |                     TTL                       |
  282.      |                                               |
  283.      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  284.      |                  RDLENGTH                     |
  285.      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
  286.      /                   RDATA                       /
  287.      /                                               /
  288.      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  289.  
  290.  
  291.  
  292.  
  293.  
  294. B. Manning/R. Colella                                           [Page 5]
  295.  
  296. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  297.  
  298.  
  299. where:
  300.  
  301.  
  302.   *  NAME: an owner name, i.e., the name of the node to which this
  303.      resource record pertains.
  304.  
  305.  
  306.   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
  307.  
  308.  
  309.   *  CLASS: two octets containing the RR IN CLASS code of 1.
  310.  
  311.  
  312.   *  TTL: a 32 bit signed integer that specifies the time interval
  313.      that the resource record may be cached before the source of the
  314.      information should again be consulted. Zero values are interpreted
  315.      to mean that the RR can only be used for the transaction in
  316.      progress, and should not be cached. For example, SOA records are
  317.      always distributed with a zero TTL to prohibit caching. Zero values
  318.      can also be used for extremely volatile data.
  319.  
  320.  
  321.   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
  322.      octets of the RDATA field.
  323.  
  324.  
  325.   *  RDATA: a variable length string of octets containing the NSAP.
  326.      The value is the binary encoding of the NSAP as it would appear in
  327.      the CLNP source or destination address field. A typical example of
  328.      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
  329.      20 (decimal); "."s have been omitted to emphasize that they don't
  330.      appear in the DNS packets.
  331.  
  332.  
  333.  
  334.                   39840f80005a0000000001e13708002010726e00
  335.  
  336.  
  337.  
  338. NSAP RRs cause no additional section processing.
  339.  
  340.  
  341. 6   The NSAP-PTR RR
  342.  
  343.  
  344. [Editors' note: the inverse mapping function is for further study. The
  345. current thinking is that NSAP structure information is stored with NSAP
  346. prefixes in Master Files and returned with queries on NSAP prefixes.
  347. Exactly how this works needs to be given more thought.]
  348.  
  349.  
  350.  
  351.  
  352.  
  353. B. Manning/R. Colella                                           [Page 6]
  354.  
  355. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  356.  
  357.  
  358. 7   Master File Format
  359.  
  360.  
  361. The format of NSAP RRs in Master Files conforms to Section 5, "Master
  362. Files," of RFC 1035. Below is an example of the use of NSAP RR in a
  363. Master File.
  364.  
  365.  
  366. [Note: the format of NSAP-PTR RRs in Master Files is for further study.]
  367.  
  368.  
  369.  
  370. ;;;;;;
  371. ;;;;;; Master File for domain tuba.ncsl.nist.gov.
  372. ;;;;;;
  373.  
  374.  
  375. @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
  376.                                     900831  ; Serial  - date
  377.                                     1800    ; Refresh - 30 minutes
  378.                                     300     ; Retry   - 5 minutes
  379.                                     604800  ; Expire  - 7 days
  380.                                     3600 )  ; Minimum - 1 hour
  381.        IN     NS     emu.ncsl.nist.gov.
  382. ;
  383. ;
  384. $ORIGIN tuba.ncsl.nist.gov.
  385. ;
  386. emu      IN  NSAP   47.0005.80.005a00.0000.0001.e137.08002010726e.00
  387.          IN  A      129.6.55.32
  388.          IN  HINFO  Sun_Sparc  SunOS_4.1.3
  389. ;
  390. osi      IN  NSAP   47.0005.80.005a00.0000.0001.e137.080020079efc.00
  391.          IN  A      129.6.55.1
  392. ;
  393. cursive  IN  NSAP   47.0005.80.005a00.0000.0001.e137.eeeeee000085.00
  394.          IN  A      129.6.224.85
  395.          IN  HINFO  PC_386  DOS_5.0/NCSA_Telnet(TUBA)
  396. ;
  397. cisco1   IN  NSAP   47.0005.80.005a00.0000.0001.e137.888888000181.00
  398.          IN  A      129.6.224.181
  399. ;
  400. 3com1    IN  NSAP   47.0005.80.005a00.0000.0001.e137.111111000111.00
  401.          IN  A      129.6.225.111
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411. B. Manning/R. Colella                                           [Page 7]
  412.  
  413. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  414.  
  415.  
  416. 8   Resolving NSAP-PTR Queries
  417.  
  418.  
  419. [Editors' note: this section is still very drafty. It's predicated on
  420. the idea of embedding the NSAP structure information in the Master Files
  421. with the RRs for NSAP prefixes.]
  422.  
  423.  
  424. The NSAP-PTR RR is defined with mnemonic "NSAP-PTR" and TYPE code
  425. 23 (decimal). It's function is analogous to the PTR record used for
  426. IP addresses [Moc87b], although the details of how it operates are
  427. different.
  428.  
  429.  
  430. NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse
  431. lookup for IP addresses due to the structure of NSAPs and the require-
  432. ments this places on the lookup process.
  433.  
  434.  
  435. The NSAP-to-name scheme operates with minimal a priori knowledge of how
  436. NSAPs are structured and operates according to a simple algorithm. Given
  437. an NSAP to be resolved, the only a priori information needed is that the
  438. first field of all NSAPs is one octet. The basic algorithm operates as
  439. follows:
  440.  
  441.  1.  build an initial query to read the record associated with the first
  442.      octet.
  443.  
  444.  2.  knowledge of the NSAP structure is not complete, so set (COMPL-KNOW
  445.      = FALSE).
  446.  
  447.  3.  send the query.
  448.  
  449.  4.  when the response is returned, if (COMPL-KNOW == TRUE), done.
  450.  
  451.  5.  construct a more detailed query with the additional structure
  452.      information from the response.
  453.  
  454.  6.  if the structure information returned in step 4 ends with a ".",
  455.      then set (COMPL-KNOW = TRUE).
  456.  
  457.  7.  go to step 3.
  458.  
  459.  
  460. The a priori knowledge required is that all NSAPs begin with an initial
  461. one-octet field, the AFI (Authority and Format Identifier, see [ISO88]);
  462. this is captured in step 1.
  463.  
  464.  
  465. Steps 3 through 7 represent a simple learning algorithm in which the
  466. resolver issues queries that are increasingly detailed until the result
  467. is obtained.
  468.  
  469. B. Manning/R. Colella                                           [Page 8]
  470.  
  471. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  472.  
  473.  
  474. Successful termination, step 4, occurs if the last query sent was based
  475. on complete NSAP structure information, as determined by the trailing
  476. ".".
  477.  
  478.  
  479. 9   Security
  480.  
  481.  
  482. Security issues are not addressed in this memo.
  483.  
  484.  
  485. 10   Authors' Addresses
  486.  
  487.  
  488. Bill Manning
  489. Rice University -- ONCS
  490. P.O. Box 1892
  491. 6100 South Main
  492. Houston, Texas 77251-1892
  493. USA
  494.  
  495.  
  496. Phone: +1.713.285.5415
  497. EMail: bmanning@rice.edu
  498. Richard Colella
  499. National Institute of Standards and Technology
  500. Technology/B217
  501. Gaithersburg, MD 20899
  502. USA
  503.  
  504.  
  505. Phone: +1 301-975-3627 (voice); +1 301 590-0932 (fax)
  506. EMail: colella@nist.gov
  507.  
  508.  
  509. A.   Issues
  510.  
  511.  
  512. A number of issues remain to be addressed.
  513.  
  514.  
  515. A.1   Relationship to X.500
  516.  
  517.  
  518. It may be useful to associate an X.500 distinguished name with an NSAP.
  519. Some thought should be given to whether this is useful and how it could
  520. be done.
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528. B. Manning/R. Colella                                           [Page 9]
  529.  
  530. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  531.  
  532.  
  533. A.2   NSAP prefixes
  534.  
  535.  
  536. Should NSAP prefixes be encoded in the DNS? This may have some useful
  537. features.
  538.  
  539.  
  540.  
  541. References
  542.  
  543. [Bry92]   P. Bryant.  NSAPs.  IPTAG/92/23 PB660, Science and Engineering
  544.           Research Council, Rutherford Appleton Laboratory, May 1992.
  545.  
  546.  
  547. [Cal92]   R. Callon.  TCP and UDP with Bigger Addresses (TUBA), a Simple
  548.           Proposal for Internet Addressing and Routing.  RFC 1347, Network
  549.           Working Group, June 1992.
  550.  
  551.  
  552. [CGC91]   R. Colella, E. Gardner, and R. Callon.  Guidelines for OSI
  553.           NSAP Allocation in the Internet.  RFC 1237, IETF OSI NSAP
  554.           Administration Working Group, July 1991.
  555.  
  556.  
  557. [GOSIP]   GOSIP Advanced Requirements Group.  Government Open Systems
  558.           Interconnection Profile (GOSIP) Version 2 [final text]. Fed-
  559.           eral Information Processing Standard, U.S. Department of
  560.           Commerce, National Institute of Standards and Technology,
  561.           Gaithersburg, MD, (Pending Publication).
  562.  
  563.  
  564. [ISO84]   ISO/IEC.  Data Interchange - Structures for the Identification
  565.           of Organization.  International Standard 6523, ISO/IEC JTC 1,
  566.           Switzerland, 1984.
  567.  
  568.  
  569. [ISO86a]  ISO/IEC. Connection Oriented Transport Protocol Specification.
  570.           International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
  571.  
  572.  
  573. [ISO86b]  ISO/IEC.  Protocol for Providing the Connectionless-mode
  574.           Network Service.  International Standard 8473, ISO/IEC JTC 1,
  575.           Switzerland, 1986.
  576.  
  577.  
  578. [ISO88]   ISO/IEC. Information Processing Systems -- Data Communications
  579.           -- Network Service Definition Addendum 2: Network Layer
  580.           Addressing.  International Standard 8348/Addendum 2, ISO/IEC
  581.           JTC 1, Switzerland, 1988.
  582.  
  583.  
  584.  
  585.  
  586.  
  587. B. Manning/R. Colella                                          [Page 10]
  588.  
  589. INTERNET-DRAFT           DNS NSAP Resource Records           May 7, 1993
  590.  
  591.  
  592. [Moc87a]  P. Mockapetris.  Domain Name -- Concepts and Facilities.  RFC
  593.           1034, Network Working Group, November 1987.
  594.  
  595.  
  596. [Moc87b]  P. Mockapetris.  Domain name -- Implementation and Specifica-
  597.           tion.  RFC 1035, Network Working Group, November 1987.
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646. Expiration Date November 7, 1993                               [Page 11]
  647.